Conversation
| func vaultPermissionForMethod(method string) (string, error) { | ||
| switch method { | ||
| case vaulttypes.MethodSecretsCreate: | ||
| return "VAULT_PERMISSION_CREATE_SECRETS", nil |
There was a problem hiding this comment.
list and delete support to be added in follow up PR
| "cre workflow delete": {}, | ||
| "cre account link-key": {}, | ||
| "cre account unlink-key": {}, | ||
| "cre secrets create": {}, |
There was a problem hiding this comment.
Needed to move to the execution layer as browser flow should not require RPC
| secID := &vault.SecretIdentifier{ | ||
| Key: item.ID, | ||
| Namespace: item.Namespace, | ||
| Owner: orgID, |
There was a problem hiding this comment.
Is this the only difference compared to web3 flow or is there more? Can we reduce the amount of c/p code between those two functions?
There was a problem hiding this comment.
Yes, I have consolidated the duplicate code. This is a good simplification.
|
|
||
| addr := common.HexToAddress(ownerAddress) // canonical 20-byte address | ||
| var label [32]byte | ||
| copy(label[12:], addr.Bytes()) // left-pad with 12 zero bytes |
There was a problem hiding this comment.
Why are we getting rid of this code? If the other side expects 32 byte prefix in the payload, then should we keep it backwards compatible?
There was a problem hiding this comment.
It's not removed, the functionality was reduced significantly and then called here: https://github.com/smartcontractkit/cre-cli/pull/324/changes#diff-76f4c29977fe8625f8281841685d4522512859fe6b978c9d796f1ba8e49ef699L270
| if err := gqlClient.Execute(ctx, gqlReq, &gqlResp); err != nil { | ||
| return fmt.Errorf("could not complete the authorization request") | ||
| } | ||
| if gqlResp.CreateVaultAuthorizationURL.URL == "" { |
There was a problem hiding this comment.
So, this is just to complete the auth flow and receive JWT? We are not sending jsonrpc2.Request payload to the Gateway yet? That kind of confuses me in this function, because it feels like we should focus on the auth flow first, and then build jsonrpc2.Request for the requested secrets operation if the auth flow was successful.
There was a problem hiding this comment.
Nvm, I see it now, you need this because we need to send the request digest and it has to be attached to JWT. But are we missing the owner address in the GQL request? This is important if someone already has a secret owned by this address and now wants to switch over to org ownership.
There was a problem hiding this comment.
Yes, that is correct.
I have not yet implemented this. I need to think further on it. For now I am treating them as two separate flows.
There was a problem hiding this comment.
nvm, it's a small implementation so I have added it.
2 participants
cre secrets create|update supports --secrets-auth browser: org-scoped encryption, digest binding, then the platform authorization step for this milestone (no browser redirect / vault submit yet).
Owner-key behavior unchanged
Note: Browser auth remains disabled in production.